An  Algorithm  for  Strengthening  State  Invariants 
Generated  from  Requirements  Specifications* 

To  be  presented  at  RE’Ol,  Toronto,  August  27—31,  2001 


Ralph  D.  Jeffords  and  Constance  L.  Heitmeyer 
Naval  Research  Laboratory  (Code  5546),  Washington,  DC  20375  USA 
{jeffords,  heitmeyer}  @itd.  nrl.  navy,  mil 


Abstract 

In  earlier  work,  we  developed  a  fixpoint  algorithm 
for  automatieally  generating  state  invariants,  proper¬ 
ties  that  hold  in  eaeh  reaehahle  state  of  a  state  ma- 
ehine  model,  from  state-based  requirements  speeifiea- 
tions.  Sueh  invariants  are  useful  both  in  validating  re¬ 
quirements  speeifieations  and  as  auxiliary  lemmas  in 
proofs  that  a  requirements  speeifieation  satisfies  other 
invariant  properties.  This  paper  deseribes  a  new  re¬ 
lated  algorithm  that  strengthens  state  invariants  gen¬ 
erated  by  our  initial  algorithm  and  demonstrates  the 
new  algorithm  on  a  simplified  version  of  an  automobile 
eruise  eontrol  system.  The  paper  eoneludes  by  deserib- 
ing  how  the  two  algorithms  were  used  to  generate  state 
invariants  from  a  requirements  speeifieation  of  a  eryp- 
tographie  deviee  and  how  the  invariants  in  eonjunetion 
with  a  theorem  prover  were  used  to  prove  formally  that 
the  deviee  satisfies  a  set  of  eritieal  seeurity  properties. 


1.  Introduction 

Automatic  generation  of  state  invariants,  properties 
that  hold  in  every  reachable  state  of  a  state  machine 
model,  can  be  valuable  in  software  development.  Not 
only  can  such  invariants  be  presented  to  system  users 
for  validation,  in  addition,  they  can  be  used  as  auxiliary 
lemmas  in  proving  other  invariant  properties.  While 
most  algorithms  for  constructing  state  invariants  oper¬ 
ate  on  programs,  we  recently  described  an  algorithm, 
called  KEEP,  for  automatically  generating  state  invari¬ 
ants  from  state-based  requirements  specifications  [18]. 
Generating  invariants  from  requirements  specifications 
rather  than  programs  has  two  major  advantages:  1)  be¬ 
cause  requirements  specifications,  unlike  programs,  are 
at  a  high  level  of  abstraction,  generation  of  and  analysis 
using  such  invariants  is  easier,  and  2)  using  invariants 
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to  detect  errors  during  the  requirements  phase  is  con¬ 
siderably  more  cost-effective  than  using  invariants  later 
in  software  development. 

This  paper  describes  a  new  algorithm  called 
GROUP  for  strengthening  state  invariants  produced 
by  the  KEEP  algorithm.  It  also  provides  evidence  of 
the  utility  of  automatically  generated  invariants  in  de¬ 
veloping  practical  systems  by  describing  how  invariants 
generated  by  KEEP  and  GROUP  were  used  to  prove 
critical  properties  of  a  secure  system. 

1.1.  A  Simple  Example 


Figure  1.  State  diagram  of  simpie  exampie. 

To  illustrate  how  the  KEEP  and  GROUP  algorithms 
may  be  used  to  generate  invariants,  we  consider  a  sim¬ 
ple  state  machine  that  defines  the  value  of  a  variable  X 
with  values  from  {xi  ,X2,X3}  comprising  the  “states”  of 
the  machine.  Figure  1  contains  a  finite  state  diagram 
describing  the  behavior  of  this  simple  state  machine. 
The  state  machine  determines  the  current  value  of  X 
from  changes  in  two  Boolean  variables  A  and  B.^  At 
each  transition  of  this  state  machine,  the  value  of  ei¬ 
ther  Aot  B  changes  but  not  both.  We  use  the  notation 
“@T(A)”  to  indicate  that  A  changes  from  false  to  true 
and  “@F(A)”  to  indicate  that  A  changes  from  true  to 
false.  Initially,  it  is  assumed  that  A  A  B  holds.  We 
say  that  the  state  machine  “enters  state  xR  if  Xi  is  an 

^This  differs  from  the  classical  finite  state  machine:  labels  on 
arrows  represent  changes  in  state  variables  rather  than  inputs. 
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initial  state  or  if  there  is  a  state  transition  satisfying 
X  ^  Xi  and  X'  =  Xi.  (We  use  an  unprimed  variable 
to  indicate  the  value  before  a  transition  and  a  primed 
variable  to  indicate  the  value  after  a  transition.)  Simi¬ 
larly,  we  say  that  the  machine  is  “in  state  a;,”  if  W  =  Xi 
and  that  the  machine  “exits  state  a;,”  if  there  is  a  state 
transition  satisfying  X  =  Xi  and  X'  ^  Xi. 

Theorem  1  describes  a  special  case  of  KEEP,  intro¬ 
duced  by  Atlee  (Theorem  3.1  from  [3]),  which  defines 
a  rule  for  testing  whether  a  literal  £,  e.g.,  A,  B,  ^A,  or 
-iB,  is  invariant  in  some  state  a;,: 

Theorem  1  A  literal  I  is  invariant  in  state  Xi  if  (a)  £ 
is  always  true  when  Xi  is  entered,  and  (b)  event  @F(£) 
eauses  an  exit  from  a;,. 

Applying  the  test  in  Theorem  1  determines  invari¬ 
ants  for  values  xi  and  X2  in  Figure  1  as  follows.  To  find 
an  invariant  with  respect  to  A  when  the  state  machine 
is  in  state  xi,  we  note  that  the  only  way  to  enter  xi 
is  either  1)  to  start  out  initially  in  xi,  in  which  case  A 
holds,  or  2)  to  enter  xi  from  X2  when  the  event  @T(A) 
occurs,  in  which  case  A  also  holds.  Thus  A  always 
holds  upon  entry  to  state  Xi .  Further,  if  in  state  Xi , 
the  event  @F(A)  occurs,  the  state  machine  exits  xi  and 
enters  X2-  Hence,  by  Theorem  1,  A  is  an  invariant  for 
state  xi-  A  similar  analysis  for  state  X2  determines 
that  -<A  is  an  invariant  for  X2-  The  KEEP  algorithm 
would  also  give  these  same  results. 

Checking  state  Xi  with  respect  to  variable  B,  we 
note  that  the  event  @F{B)  causes  exit  from  xi  and 
that  B  holds  in  the  initial  state.  However,  whether 
B  holds  if  the  system  enters  xi  from  X2  is  unknown. 
Hence,  we  cannot  determine  whether  B  is  an  invariant 
for  xi  using  Theorem  1.  A  similar  situation  occurs 
for  state  X2-  The  KEEP  algorithm  exhibits  the  same 
limitations. 

To  overcome  these  limitations,  our  new  GROUP  al¬ 
gorithm  treats  the  two  states  xi  and  X2  together  as 
a  set  {xi,X2}-  For  example,  upon  entry  into  the  set 
{xi,X2},  B  is  true  (due  to  the  initial  state  assump¬ 
tion).  Further,  if  the  system  is  already  in  {xi,X2}, 
the  event  @F{B)  causes  exit  from  {xi,X2}  and  entry 
into  x^.  Hence,  B  is  an  invariant  for  both  x\  and  X2- 
This  illustrates  the  central  idea  of  our  new  algorithm 
GROUP,  which  is  to  apply  Theorem  1  to  a  “group”  of 
states  treated  as  a  superstate. 

Given  G,  a  subset  of  states,  our  new  theorem  de¬ 
scribes  the  test  that  GROUP  applies  to  decide  whether 
a  literal  £  is  an  invariant  for  each  state  in  G: 

Theorem  2  A  literal  £  is  invariant  in  state  x  for  eaeh 
X  in  G  if  (*)  £  is  always  true  upon  entry  to  G  ( either 
in  G  initially  or  via  a  transition  from  some  state  not 
in  G),  and  (**)  event  @F(£)  eauses  an  exit  from  G. 


1.2.  Organization  of  the  Paper 

This  paper  introduces  our  new  algorithm  GROUP, 
a  companion  to  KEEP,  for  generating  state  invariants 
from  requirements  specifications  in  the  SCR  (Software 
Cost  Reduction)  tabular  notation.  To  provide  back¬ 
ground,  Section  2  reviews  the  formal  model,  the  special 
notation,  and  tools  associated  with  SCR.  To  demon¬ 
strate  how  the  GROUP  algorithm  is  used  in  conjunc¬ 
tion  with  the  KEEP  algorithm.  Section  3  shows  how 
special  state  invariants  called  “mode  invariants”  can  be 
derived  from  a  mode  transition  table  (a  type  of  table 
appearing  in  SCR  specifications)  by  applying  KEEP 
and  how  these  mode  invariants  can  be  strengthened  by 
applying  GROUP.  Section  4  formalizes  Theorem  2  and 
the  corresponding  GROUP  algorithm.  It  also  describes 
a  more  complete  algorithm  that  applies  to  more  general 
systems,  such  as  nondeterministic  systems.  This  more 
general  result  should  be  applicable  to  other  state  ma¬ 
chine  models.  To  demonstrate  the  practical  utility  of 
automatically  generated  invariants.  Section  5  describes 
how  invariants  constructed  with  KEEP  and  GROUP 
were  used  as  auxiliary  lemmas  in  proving  three  critical 
security  properties  of  a  requirements  specification  for  a 
cryptographic  device.  Finally,  Sections  6  and  7  discuss 
related  work  and  present  some  conclusions. 

2.  Background:  SCR  Method 

The  SCR  requirements  method  is  designed  to  de¬ 
tect  and  correct  errors  during  the  requirements  phase 
of  software  development.  Originally  formulated  to  doc¬ 
ument  the  requirements  of  the  flight  program  for  the 
U.S.  Navy’s  A-7  aircraft  [17],  the  SCR  method  has  been 
used  by  many  organizations  in  industry  (e.g..  Bell  Lab¬ 
oratories,  Grumman,  Ontario  Hydro,  and  Lockheed)  to 
specify  the  requirements  of  practical  systems. 

2.1.  The  SCR  Model  and  Tools 

An  SCR  requirements  specification  describes  a  non¬ 
deterministic  environment  and  the  required  system  be¬ 
havior  (usually  deterministic)  [15].  Monitored  (also 
called  input)  variables  and  eontrolled  (also  called  out¬ 
put)  variables,  represent  the  environmental  quantities 
that  the  system  monitors  and  controls.  The  environ¬ 
ment  nondeterministically  generates  a  sequence  of  in¬ 
put  events,  where  each  input  event  changes  some  moni¬ 
tored  variable.  Each  input  event  may  cause  the  system 
to  change  one  or  more  of  the  controlled  variables. 

In  SCR,  NAT  and  REQ,  two  relations  of  the  Eour 
Variable  Model  [23],  describe  the  required  system  be¬ 
havior.  NAT  describes  physical  constraints  on  the  en¬ 
vironment;  REQ  describes  the  relation  between  moni¬ 
tored  and  controlled  variables  that  the  system  must  en- 
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force.  To  specify  REQ  concisely,  SCR  specifications  use 
two  types  of  auxiliary  variables:  mode  classes,  whose 
values  are  modes,  and  terms.  Both  mode  classes  and 
terms  may  be  used  to  capture  historical  information. 

More  formally,  an  SCR  system  E  is  represented  as 
a  state  machine  E  =  (5, 5o ,  E™ ,  T) ,  where  S  is  the  set 
of  states,  5o  C  5  is  the  initial  state  set,  E™  is  the  set 
of  input  events,  and  the  transform  T  maps  each  input 
event  and  old  state  to  a  new  state  [15].  A  simplifying 
assumption,  called  the  One  Input  Assumption,  states 
that  exactly  one  input  event  occurs  at  each  state  tran¬ 
sition.  The  transform  T  is  the  composition  of  smaller 
functions,  called  table  functions,  derived  from  the  ta¬ 
bles  in  an  SCR  requirements  specification.  Each  table 
defines  a  term,  a  mode  class,  or  a  controlled  variable. 

The  SCR  requirements  model  includes  a  set  RF  = 
{ri,r2,  ■  ■  ■  ,r„}  containing  the  names  of  all  state  vari¬ 
ables  in  a  given  specification  and  a  function  TY  map¬ 
ping  each  variable  to  its  type,  i.e.,  set  of  legal  values. 
In  the  model,  a  state  is  a  function  mapping  each  vari¬ 
able  r  to  some  value  in  TY  (r) ,  a  condition  is  a  pred¬ 
icate  defined  on  the  system  state,  and  an  event  is  a 
predicate  defined  on  two  successive  system  states  that 
denotes  some  change  between  those  states.  The  no¬ 
tation  “@T(c)  WHEN  d”  denotes  a  conditioned  event, 
defined  as 

@T(c)  WHEN  d  =*'  A  c'  A  d.  (1) 

Informally,  “@T(c)  WHEN  d”  means  that  c  is  false  in 
the  old  state  and  changes  to  true  in  the  new  state,  while 
d  is  true  in  the  old  state  but  unrestricted  in  the  new 
state.  In  this  paper,  both  -ic  and  c  denote  the  negation 
of  condition  c. 

Introduced  in  1995,  the  SCR  toolset  [14,  15,  16]  is  an 
integrated  suite  of  tools  supporting  the  SCR  method. 
The  tools  include  a  specification  editor  for  creating  the 
specification,  a  simulator  for  validating  that  the  speci¬ 
fication  satisfies  the  customer’s  intent  [14],  and  a  con¬ 
sistency  checker  [15]  to  analyze  the  specification  for 
properties  such  as  syntax  and  type  correctness,  deter¬ 
minism,  case  coverage,  and  absence  of  circularity.  The 
toolset  also  contains  a  model  checker,  a  verifier  called 
TAME  [2] ,  a  property  checker  called  Salsa  [6] ,  and  an 
automatic  invariant  generator  [18],  which  implements 
the  KEEP  algorithm. 

The  utility  of  the  SCR  tools  has  been  demonstrated 
in  several  projects  involving  real-world  systems.  In  one 
project,  NASA  researchers  used  the  SCR  consistency 
checker  to  detect  missing  assumptions  and  ambiguity 
in  the  requirements  specification  of  the  International 
Space  Station  [11].  In  a  second  project,  engineers  at 
Rockwell  Aviation  used  the  SCR  tools  to  detect  28  er¬ 
rors,  many  of  them  serious,  in  the  requirements  specifi¬ 


cation  of  a  flight  guidance  system  [22].  Recently,  NRL 
used  the  SCR  tools  to  uncover  numerous  errors,  includ¬ 
ing  a  safety  violation,  in  a  sizable  contractor-produced 
requirements  specification  of  a  weapons  control  panel 
for  a  safety-critical  U.S.  military  system  [13]. 

2.2.  Modes  and  Mode  Invariants 

Three  kinds  of  tables  found  in  most  SCR  specifica¬ 
tions  are  mode  transition  tables,  condition  tables,  and 
event  tables.  Although  this  paper  focuses  on  the  gen¬ 
eration  of  invariants  from  mode  tables,  extending  the 
GROUP  algorithm  to  event  tables  is  straightforward 
(just  as  extending  KEEP  to  event  tables  is  straightfor¬ 
ward  [18]). 

Eigure  2  contains  a  mode  transition  table,  part  of  an 
SCR  specification  for  an  Automobile  Cruise  Control 
System  [16].  The  table  defines  the  values  of  a  mode 
class  M.  In  isolation,  a  mode  class,  its  initial  states, 
its  inputs,  and  its  transitions — which  we  call  a  mode 
machine — may  be  viewed  as  a  very  simple  system  E 
with  a  single  dependent  variable,  a  mode  class  M.  In 
this  machine,  the  mode  is  the  “state”  referred  to  in 
the  simple  example  in  Section  1.  A  mode  transition 
table  represents  the  transitions  of  a  mode  machine  in 
a  tabular  format.  The  inputs  of  the  mode  machine  are 
the  variables  appearing  in  the  predicates  that  define 
the  transitions.  We  informally  say  that  the  condition 
g  is  a  mode  invariant  for  mode  m  if  M  =  m=>q  is  & 
state  invariant. 

In  the  Cruise  Control  system,  the  set  of  state 
variables  RF  is  defined  by  RF  =  {ignOn,  Lever, 
EngRunning,  Brake,  M},  where  IgnOn,  Lever, 
EngRunning,  and  Brake  are  monitored  variables  and  M 
is  a  mode  class  with  values  in  the  set  {Off,  Inactive, 
Cruise,  Override).  The  variables  IgnOn,  EngRunning, 
and  Brake  are  Boolean;  the  variable  Lever  has  the  enu¬ 
merated  type  {off,  const,  resume,  release).  In 
the  initial  states  of  Cruise  Control,  both  IgnOn  and 
EngRunning  are  false  and  M  =  Off. 

Eigure  2  defines  the  transform  T  for  this  simple  sys¬ 
tem.  T  maps  the  old  state  and  an  event,  a  change  in 
the  value  of  one  of  the  monitored  variables,  to  a  new 
state.  Eor  example,  the  third  row  of  Eigure  2  states 
that  if  the  system  is  in  mode  Inactive  and  the  event 
@T  (Lever  =  const)  occurs  when  the  engine  is  run¬ 
ning  but  the  brake  is  not  applied,  then  the  new  mode 
is  Cruise.  If,  in  a  given  state,  none  of  the  events  defin¬ 
ing  transitions  from  the  current  mode  occurs  (yet  some 
input  event  has  occurred),  then  there  is  no  change  in 
mode.  Eor  example,  if  the  system  is  in  mode  Inactive 
and  the  brake  is  on  when  @T(Lever  =  const)  occurs, 
the  system  remains  in  Inactive.  This  is  because  neither 
event  that  triggers  exit  from  Inactive  can  occur:  the 
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Old  Mode  M 

Event 

New  Mode  M 

1  Off 

@T(lgnOn) 

Inactive 

2  Inactive 

@F(lgnOn) 

Off 

3  Inactive 

@T(Lever  =  const)  WHEN  EngRunning  AND  NOT  Brake 

Cruise 

4  Cruise 

@F(lgnOn) 

Off 

5  Cruise 

@  F  ( EngRunning) 

Inactive 

6  Cruise 

@T(Brake)  OR  @T(Lever  =  off) 

Override 

7  Override 

@F(lgnOn) 

Off 

8  Override 

@  F  ( EngRunning) 

Inactive 

9  Override 

@T(Lever  =  resume)  WHEN  NOT  Brake  OR 
@T(Lever  =  const)  WHEN  NOT  Brake 

Cruise 

Initially:  M  =  Off  A  -ilgnOn  A  -lEngRunning 


Figure  2.  Mode  Transition  Tabie  for  Cruise  Controi. 


brake  is  on  means  that  @T(Lever  =  const)  WHEN 
EngRunning  AND  NOT  Brake  does  not  occur,  while 
the  One  Input  Assumption  prevents  the  occurrence  of 
@F(lgnOn). 

3.  State  Invariants  for  Cruise  Control 

Section  3.1  briefly  reviews  the  KEEP  algorithm  in¬ 
troduced  in  [18]  by  applying  KEEP  to  the  mode  tran¬ 
sition  table  in  Figure  2.  Then,  Section  3.2  describes 
the  new  GROUP  algorithm  by  showing  how  the  state 
invariants  generated  by  KEEP  can  be  strengthened  by 
applying  GROUP. 

3.1.  Applying  the  KEEP  Algorithm 

Our  technique  automatically  generates  mode  in¬ 
variants  from  propositional  formulas  extracted  from  a 
mode  machine  and  constraints  on  the  input  variables 
associated  with  that  mode  machine.  To  compute  the 
mode  invariants  for  the  mode  class  M,  we  first  iden¬ 
tify  the  input  variables  appearing  in  the  events  of  the 
mode  transition  table  and  in  any  constraints  on  the 
mode  machine  (such  as  the  One  Input  Assumption). 
We  then  choose  a  set  of  atomic  conditions  that  provides 
a  sufficient  basis  for  a  Boolean  encoding  of  all  events 
in  the  table  and  these  constraints.  For  example,  in  the 
Cruise  Control  specification,  we  choose  the  atomic  con¬ 
ditions  I  =  IgnOn,  E  =  EngRunning,  B  =  Brake,  O  = 
Lever=off,  C  =  Lever=const,  R  =  Lever=resume, 
and  L  =  Lever=release.^  Below,  the  term  literal 
refers  to  either  an  atomic  condition  or  its  negation. 
The  KEEP  algorithm  consists  of  the  following  three 
steps,  repeated  until  a  flxpoint  is  reached: 

1.  For  each  mode  to,  compute  the  mode  entry  eondi- 
tion  N{m),  the  disjunction  of  the  conditions  which 
may  be  true  upon  entry  into  mode  to. 

^Our  Boolean  encoding  assigns  one  atomic  condition  for  each 
of  the  four  values  of  Lever  even  though  Figure  2  mentions  only 
three  of  these  values. 


2.  For  each  mode  to,  compute  the  exit  set  X(m), 
where  X{m)  is  the  set  of  literals,  each  of  whose 
falsification  causes  exit  from  to. 

3.  For  each  mode  to,  compute  the  mode  invariant 
P(m)  by  removing  from  each  disjunct  in  N(m) 
all  literals  that  are  not  members  of  X{m),  while 
“keeping”  those  literals  which  are  members  of 
X{m).  More  precisely,  replace  each  literal  that 
is  not  in  X(m)  by  true. 

Let  Ni{m),  Xi{m),  and  Pi{m)  represent  the  values 
of  the  mode  entry  condition,  the  exit  set,  and  the  in¬ 
variant  for  mode  to  at  the  end  of  the  ith  pass  of  the 
algorithm.  During  each  pass,  a  number  of  additional 
facts  may  be  used  to  strengthen  the  invariant:  environ¬ 
mental  constraints,  such  as  the  One  Input  Assumption; 
constraints  on  enumerated  type  variables;  and  invari¬ 
ants  computed  on  previous  passes.  A  constraint  on  an 
enumerated  type  (needed  due  to  our  Boolean  encoding) 
simply  states  that  an  enumerated  type  variable  has  ex¬ 
actly  one  value.  For  example,  in  the  Cruise  Control 
System,  C  ^  OaRaL. 

Applying  KEEP  to  the  mode  transition  table  in  Fig¬ 
ure  2  produces  the  mode  entry  conditions,  the  exit  sets, 
and  the  invariants  shown  in  Figure  3  on  the  first  pass. 
Because  applying  KEEP  on  the  second  pass  does  not 
change  these  results,  the  algorithm  reaches  a  flxpoint 
on  the  second  pass.  Thus,  two  passes  of  KEEP  gener¬ 
ate  the  following  state  invariants: 

•  M  =  Off  =>  -ilgnOn 

•  M  =  Cruise  -iBrake  A  Lever  ^  off 

•  M  =  Override  true 

•  M  =  Inactive  true 
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Mode  m 

Ni  (m) 

Xi{m) 

Pi{m) 

Off 

1  V  1  V  1  V  Ia'e 

m 

1 

Cruise 

CaEaBaOaRaL  V  CaBaOaRaL  V  RaBaOaCaL 

{I,E,B,0} 

BaO 

Override 

BaO  V  OaBaCaRaL 

{I,E} 

true 

Inactive 

I  V  EaOa'B  V  E 

{1} 

true 

Figure  3.  Mode  Invariant  Generation  for  Cruise  Control 


To  illustrate  the  GROUP  algorithm,  we  slightly 
modified  the  table  in  [18]  to  produce  the  table  in  Fig¬ 
ure  2.  Figure  2  omits  IgnOn  from  the  WHEN  clause 
for  transition  3  and  IgnOn  and  EngRunning  from  the 
WHEN  clauses  for  transition  9.  Due  to  these  modi¬ 
fications  to  the  table,  the  KEEP  algorithm  generates 
weaker  invariants  than  the  algorithm  generated  for  the 
original  table  in  [18].  However,  as  Section  3.2  will  show, 
the  GROUP  algorithm  generates  the  remaining  invari¬ 
ants. 

3.2.  Applying  the  GROUP  Algorithm 

Suppose  TY  (M)  is  the  set  of  modes  of  a  mode  class 
M,  L  is  a  set  of  literals,  and  X{m)  is  the  exit  set  for 
each  TO  in  TY{M).  Eor  each  candidate  H  in  L,  the 
GROUP  algorithm  consists  of  the  following  four  steps: 

1.  Let  G  be  the  largest  subset  of  TY{M)  such  that, 
for  all  TO  in  G,  £  belongs  to  X{m). 

2.  If  for  some  to  in  G,  (*)  of  Theorem  2  fails  to 
hold  (i.e.,  there  is  some  to  in  G  whose  mode  en¬ 
try  condition — either  initially  or  from  some  mode 
outside  of  G — does  not  imply  £),  then  remove  to 
from  G. 

3.  If  for  some  to  in  G,  (**)  of  Theorem  2  fails  to  hold 
because  @E(£)  causes  transition  to  some  other 
mode  to'  in  G,  then  remove  to'  from  G. 

4.  Repeat  steps  2  and  3  until  no  more  modes  may  be 
eliminated  from  G. 

Step  1  is  natural  since  it  provides  the  largest  poten¬ 
tial  G.  Step  2  is  also  straightforward.  However,  note 
that  step  3  removes  to'  (not  to)  when  (**)  fails.  While 
removal  of  to  would  be  sound,  it  produces  weaker  in¬ 
variants.  This  shows  that  the  translation  of  even  a 
simple  intuitive  criterion  (such  as  the  criterion  in  Theo¬ 
rem  2)  to  an  appropriate  algorithm  requires  careful  de¬ 
liberation.  As  with  KEEP,  environmental  constraints 
and  constraints  on  enumerated  types  may  always  be 
used  to  strengthen  invariants.  Also  similar  to  KEEP, 
more  than  one  pass  may  be  required  because  invariants 
computed  during  one  pass  may  either  strengthen  the 
mode  entry  conditions  N{m)  or  increase  the  exit  sets 
A  (to)  for  the  next  pass. 


To  illustrate  the  GROUP  algorithm,  we  apply  it  to 
the  Cruise  Control  example.  Step  1  of  the  algorithm 
limits  our  choice  of  £  to  members  of  Xi{m)  in  Eigure  3. 
Applying  the  GROUP  algorithm  to  this  example  pro¬ 
duces  nontrivial  results  for  two  cases:  the  literals  I 
and  E.  Consider  the  case  in  which  £  =  I.  At  step  1, 
G  =  {Cruise, Override, Inactive), since  I  belongs  to 
the  exit  set  Ai(to)  of  each  mode  to  in  G  (see  Eigure  3). 
At  step  2,  (*)  holds,  since  the  only  possible  entry  into 
G  is  from  Off  into  Inactive,  and  Eigure  4  shows  that 
I  holds  upon  entry  into  Inactive.^  At  step  3,  (**) 
holds,  since  each  occurrence  of  @E(7)  from  a  mode  in 
G  causes  an  exit  to  Off,  a  mode  outside  G.  Hence, 
the  GROUP  algorithm  determines  that  the  initial  G 
satisfies  Theorem  2  after  a  single  pass. 


Mode  m 

Mode  entry  from  outside  G 

New  invariant 

Cruise 

false 

/ 

Override 

false 

/ 

Inactive 

I 

/ 

Figure  4.  GROUP  for  Cruise  Control  (7  =  I) 

In  the  case  oi  £  =  E,  at  step  1,  G  =  {Cruise, 
Override).  Step  2  computes  the  mode  entry  condi¬ 
tion  from  outside  G,  which  is  limited  to  transition  3  of 
Figure  2.  This  transition  from  Inactive  to  Cruise  is 
triggered  by  the  event  @T(G)  WHEN  E  A  B,  which 
means  that  G  holds  in  the  new  state  and  both  E  and 
B  hold  in  the  old  state.  Because  GROUP  computed 
I  as  an  invariant  of  Inactive,  I  also  holds  in  the  old 
state.  Because  of  the  One  Input  Assumption,  the  three 
old  state  values  are  preserved  in  the  new  state.  Finally, 
the  enumerated  type  constraint  means  that  O  A  R  A  L 
also  holds  in  the  new  state  (see  Figure  5).  (Although 
not  shown  in  this  example,  previously  computed  in¬ 
variants  and  enumerated  constraints — besides  the  One 
Input  Assumption — can  be  critical  for  ensuring  that 
the  mode  entry  condition  implies  £.)  As  in  the  first 
case,  GROUP  determines  that  the  initial  G  satisfies 
Theorem  2  after  a  single  pass. 

In  summary.  Figure  4  indicates  that  to  € 
{Cruise,  Override,  Inactive)  IgnOn,  and  Figure  5 
shows  that  to  €  {Cruise, Override)  EngRunning. 

®The  entries  labeled  false  in  Figure  4  indicate  that  the  system 
can  never  enter  Cruise  or  Override  from  outside  G. 
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Mode  m 

Mode  entry  from  outside  G 

New  invariant 

Cruise 

CaIaEaBaOaRaL 

E 

Override 

false 

E 

Figure  5.  GROUP  for  Cruise  Controi  {£  =  E) 


Combining  the  invariants  generated  by  the  GROUP  al¬ 
gorithm  with  those  generated  by  the  KEEP  algorithm 
produces  strengthened  invariants  as  follows: 

•  M  =  Off  =>  -ilgnOn 

•  M  =  Cruise  =>  IgnOn  A  EngRunning  A 
-iBrake  A  Lever  off 

•  M  =  Override  IgnOn  A  EngRunning 

•  M  =  Inactive  IgnOn 

While  the  invariant  for  mode  Off  is  unchanged,  each  of 
the  remaining  three  mode  invariants  are  strengthened. 

Thus  combining  KEEP  and  GROUP  derives  the 
same  invariants  for  the  modified  table  in  Figure  2  as 
the  KEEP  algorithm  alone  derived  for  the  original  ta¬ 
ble  in  Cruise  Control  [18].  It  is  now  easy  to  show  that 
the  two  tables  are  equivalent:  the  inclusion  of  I  in  the 
WHEN  clause  for  transition  3  in  the  original  table  is 
redundant — adding  it  back  to  the  modified  system  will 
cause  no  change  in  behavior  since  we  know  that  I  is  in¬ 
variant  for  mode  Inactive;  a  similar  argument  holds 
for  the  other  modifications  to  the  table.  With  this  ob¬ 
servation,  one  may  prefer  the  modified  table  in  Figure  2 
in  certain  contexts  (e.g.,  in  doing  analysis  of  the  specifi¬ 
cation)  since  it  has  less  redundant  information  encoded 
in  the  WHEN  clauses. 

4.  A  Formal  Treatment  of  GROUP 

This  section  formally  defines  and  extends  concepts 
described  informally  above.  Section  4.1  defines  a  mode 
machine  as  an  abstract  state  machine.  Section  4.2 
formalizes  Theorem  2,  and  Section  4.3  gives  a  more 
general,  but  less  intuitive,  formalization  that  also  ap¬ 
plies  to  nondeterministic  systems  and  to  mode  tables 
with  self-transitions.  The  weaker  formalization  in  Sec¬ 
tion  4.2  appears  so  far  to  be  sufficient  in  practice. 
While  much  of  the  notation  in  this  section  is  borrowed 
from  [13]  and  [18],  some  definitions  have  been  simpli¬ 
fied.  The  proofs  of  the  two  theorems  presented  in  this 
section  appear  in  [19].  The  correctness  of  our  results 
has  been  checked  using  the  PVS  prover  [10]. 

4.1.  Mode  Machines  as  Abstract  State  Machines 

We  represent  a  system  as  a  state  machine  E  = 
(5,  0,p),  where  S  is  the  set  of  states,  0  is  the  ini¬ 
tial  state  predicate,  and  p  is  the  next-state  relation  on 


pairs  of  states.  To  define  the  state  machine  E  corre¬ 
sponding  to  an  SCR  machine  (5,  5o,E™,T),  we  define 
1)  the  initial-state  predicate  0  on  a  state  s  £  S  such 
that  0(s)  is  true  iff  s  €  5o  and  2)  the  next-state  pred¬ 
icate  p  on  pairs  of  states  s,  s'  €  S  such  that  p(s,  s') 
is  true  iff  there  exists  an  event  e  €  E™,  enabled  in  s, 
such  that  T(e,  s)  =  s'.  Thus  the  predicate  p  is  simply  a 
concise  and  abstract  way  of  expressing  the  transform  T 
without  reference  to  events. 

A  full  SCR  specification  modeled  as  a  state  machine 
E  =  (5,  0,p)  has,  for  each  mode  class,  an  abstraction 
E^  =  {Sa,P>a,  Pa)  that  is  a  mode  machine.  We  define 
abstraction  so  that  a  mode  invariant  qa  computed  for 
a  mode  machine  E^  corresponds  to  a  mode  invariant  q 
in  the  overall  state  machine  E.  See  [18]  for  details. 

Suppose  M  is  a  mode  class,  TY (M)  the  set  of  possi¬ 
ble  values  (i.e.,  modes)  of  M,  and  Ea  the  set  of  events 
in  the  mode  transition  table  for  M.  As  in  [18],  four 
constructs  define  the  mode  machine  for  mode  class  M : 
the  relation  describing  the  mode  transitions,  the 
initial  state  predicate  Qa,  and  two  predicates  C\  and 
C2  on  the  monitored  variables  of  E^,  which  capture 
environmental  constraints: 

•  is  a  relation  on  Ty(M)  xTy(M).  In  SCR 
specifications,  this  relation  is  represented  by  the 
Boolean  encoded  form  of  the  mode  transition  table 
for  M.  We  assume  that  has  no  self-transitions, 
i.e.,  transitions  of  the  form  {m,e,m). 

•  0/1  is  the  condition  over  E/i  which  describes  the 
initial  states.  Additionally,  we  define  the  initial 
states  associated  with  each  m  £  TY{m)  as  6 Aim), 
where  OaUti)  =  {s  j  0/i(s)  A  s{M)  =  to}. 

•  Cl  is  a  conjunction  of  encoded  constraints  on  mon¬ 
itored  variables  in  a  single  state.  Among  these 
constraints  are  the  axioms  needed  to  encode  finite 
types  as  mutually  exclusive  Booleans.  Other  con¬ 
straints  are  derived  from  NAT. 

•  C2  is  a  conjunction  of  encoded  constraints  on  mon¬ 
itored  variables  in  two  eonseeutive  states.  One 
constraint  C2  for  the  Cruise  Control  system  is  the 
One  Input  Assumption. 

4.2.  Formalization  of  Theorem  2  and  GROUP 

To  formalize  Theorem  2  and  the  GROUP  algorithm, 
we  borrow  two  functions  from  [18] :  NEW,  which  is  used 
to  define  the  mode  entry  conditions,  and  EX,  which 
is  used  to  define  the  exit  sets.  Also  required  in  the 
formalization  are  a  variant  of  EX  called  EX~^ ,  the  exit 
set  A  (to),  and  a  variant  of  the  mode  entry  condition 
N{m)  denoted  N~^{rh,m). 
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The  function  NEW,  defined  formally  in  [18],  com¬ 
putes  the  strongest  condition  known  to  be  true  upon 
entry  into  the  new  state.  Applying  NEW  to  a  two- 
state  predicate  in  Disjunctive  Form,  i.e.,  a  disjunction 
of  non-/a/se  terms,  simply  replaces  each  old  state  literal 
with  the  literal  true  and  suppresses  the  primes  on  the 
remaining  new  state  literals.  For  example,  the  follow¬ 
ing  shows  how  the  event  in  transition  3  in  Figure  2  can 
be  rewritten  first  by  applying  (1),  next  by  applying  the 
One  Input  Assumption,  and  third  by  applying  NEW'. 

NEW{m{C)  WHEN  EhB)  = 
NEW(C^C'^Ef^)  = 

NEW{CnC'  ^E^B^E'  hS')  =  CaEaB. 

The  GROUP  algorithm  requires  two  versions  of  the 
function  EX.  The  version  in  [18]  defines  a  two-state 
predicate  which  describes  the  events  causing  exit  from 
TO  as  a  disjunction.  Formally,  EX  is  defined  by 


EX{m)  V 

\e,m'  (m,e,m') 

Applying  this  definition  to  lines  2  and  3  of  Figure  2 
means  that 

EA(lnactive)  =  @F(7)  V  @T(C')  WHEN  (EaB). 

The  second  version,  EX^ ,  a  slight  modification  to  de¬ 
scribe  an  exit  from  G,  is  a  two-state  predicate  which  is 
the  same  except  for  the  qualifier  m'  ^  G.  This  predi¬ 
cate  is  defined  by 


EX+(to,G)  =*' 


V 


\e  ,m'  :m'  ^m^m'  ^G&TA(m,e,m' 


Eor  example, 

EX+ (Cruise,  {Cruise,  Override})  =  @E(7)  V  @F{E). 

Also  needed  are  the  exit  sets  X{m)  and  the  mode 
entry  conditions  N^{m,m).  In  both  definitions,  P  is 
the  vector  of  invariants  (computed  prior  to  the  applica¬ 
tion  of  GROUP)  known  to  hold  in  the  old  state.  Each 
exit  set  X  (to)  is  the  set  of  literals  whose  falsification 
in  the  context  of  known  invariants  and  environmental 
conditions  causes  exit  from  m:'^ 

X{m)  =*'  {I  1  @E(7)  A  P{m)  A  G2  ^  EX{m)}. 

■^This  definition  is  slightly  less  general  than  the  definition 
in  [18].  However,  in  practice,  use  of  this  definition  for  both 
KEEP  and  GROUP  appears  to  cause  no  loss  of  precision  in  the 
computed  invariants. 


Each  N~^{m,m)  defines  the  mode  entry  condition  into 
mode  TO  from  mode  to.  N~^(m,  to),  a  special  case  of  the 
mode  entry  condition  N{m)  (defined  formally  in  [18]), 
is  defined  by 

N+{m,m)=^  i  y  NEW{P{m)  AC2  Ae)]ACi. 

ye:TA(m,e,m)  J 

To  show  that  this  definition  correctly  captures  our 
intuitive  notion  of  what  is  known  upon  mode  entry, 
a  more  formal  computation  of  the  mode  entry  con¬ 
dition  (Cruise,  Override)  for  the  Cruise  Control 
follows: 

(Cruise,  Override)  =  NEW[{P{CrvLise)  A  C2 
A{@T{B)  V  @T(0))]  AGi 
=  NEW[BaO  AC2A  (BaB'  V  OaO')]  a  Gi 
=  NEW[BaB'aOaO'  V  OaO'aBab']  a  Cl 
=  [BaO  V  OaB]  a  Cl 
=  BaO  V  OaHaGaEaL 

In  the  above  computation,  C2  represents  the  One  Input 
Assumption  and  Gi  the  enumerated  type  constraint 
O  <1^  CaRaE. 

Next,  we  present  Theorem  3,  a  formalization  of  The¬ 
orem  2: 

Theorem  3  M  =  m  i  is  a  state  invariant  for  eaeh 
m  in  G  of  a  deterministie  mode  maehine  if  for  eaeh 
TO  e  G;  (*)  6 Aim)  A  Gi  i;  N~^{m,m)  £  for  eaeh 
rh^G,  and  (**)  @E(7)  A  P(to)  A  G2  ^  EX+{m,G). 

The  GROUP  algorithm  is  derived  from  Theorem  3: 

To  test  if  some  literal  £  is  an  invariant: 

(a)  Initially  choose  G  to  be  all  modes  to  for  which 
@E(7)  causes  exit  from  to,  i.e.,  £  belongs  to  X{m). 

(b)  If  for  some  mode  to  in  G  (*)  fails,  then  remove  to 
from  G. 

(c)  If  for  some  mode  to  in  G  there  is  some  m'{^  to) 
in  G  and  event  e  such  that  T^(to,  e,TO')  and  the 
formula  @E(7)  A  P{m)  A  G2  A  e  is  satisfiable  (i.e., 
the  formula  holds  for  some  state  pair  (s,s')),  then 
remove  to'  from  G. 

(d)  Repeat  steps  (b)  and  (c)  until  no  more  modes  may 
be  removed. 

There  is  a  subtlety  to  the  test  in  step  (c):  it  detects 
the  special  case  of  the  failure  of  (**)  when  to'  is  reach¬ 
able  from  TO  via  the  occurrence  of  e.  If  (**)  fails 
but  to'  is  not  reachable  via  the  occurrence  of  e  (i.e.. 
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@F(£)  A  P{m)  A  (^2  A  e  is  unsatisfiable)  then  we  may 
ignore  this  case  as  it  has  no  effect.  In  such  situations, 
the  event  e  should  never  have  been  included  in  the 
definitions  of  EX{m)  or  EX~^{m,G).  Making  this  re¬ 
striction  in  general,  however,  would  complicate  matters 
for  the  KEEP  algorithm,  where  the  distinction  is  irrel¬ 
evant.  Such  subtleties  are  easily  overlooked  in  informal 
proofs  of  algorithm  correctness  but  are  essential  in  our 
formal  proofs  using  PVS. 

4.3.  A  More  General  Formalization 

The  more  general  formalization  of  Theorem  2 
applies  to  nondeterministic  systems,  allows  self¬ 
transitions  in  the  mode  table,  and  handles  the  more 
general  definition  of  X{m)  in  [18].  We  give  an  infor¬ 
mal  exposition  of  this  more  general  result.  For  formal 
details  and  the  transcription  of  this  Theorem  to  a  more 
general  version  of  the  GROUP  algorithm,  see  [19]: 

Theorem  4  (More  General  Pormalization) :  Eor  a 
given  literal  I  and  subset  of  modes  G,  if  for  eaeh  m  €  G: 
(#)  Assuming  I  is  an  invariant  for  all  of  G  -^{m} 
means  I  is  true  upon  entry  to  m  and  (##)  @F(£)  al¬ 
ways  enables  exit  from  mf"  then  we  eonelude  that  I  is 
a  mode  invariant  for  eaeh  m  G  G. 

5.  Applying  Invariants  in  Practice 
5.1.  A  Cryptographic  Device  CD 

COMSEC  (Communications  Security)  devices,  de¬ 
vices  which  manage  encrypted  communications,  are  vi¬ 
tal  to  the  correct  operation  of  U.S.  military  systems. 
CD  is  a  COMSEC  device  designed  to  provide  cryp¬ 
tographic  processing  for  a  U.S.  Navy  radio  receiver. 
CD,  based  on  a  technology  for  implementing  COM¬ 
SEC  devices  in  software  as  well  as  hardware,  presents 
a  new  challenge  in  the  development  of  COMSEC  de¬ 
vices.  While  a  solid  base  of  experience  exists  for  im¬ 
plementing  trustworthy  COMSEC  devices  in  hardware, 
implementing  COMSEC  devices  in  software  is  rare. 

To  provide  a  high  degree  of  assurance  in  the  cor¬ 
rectness  of  CD’s  specification,  we  applied  the  SCR 
tools  [20].  Our  results  suggest  that  applying  SCR  in 
the  development  of  COMSEC  devices  of  moderate  size 
and  complexity  is  practical,  effective,  and  low-cost.  In 
approximately  one  person-month,  we  were  able  to  rep¬ 
resent  a  significant  subset  of  a  prose  requirements  doc¬ 
ument  for  CD  in  the  SCR  notation  and  to  establish 
that  the  SCR  specification  satisfies  seven  critical  secu¬ 
rity  properties.  The  SCR  specification  of  CD  is  mod¬ 
erately  complex,  consisting  of  39  variables  (17  input 

®We  say  “enables  exit  from  m”  since  a  nondeterministic  sys¬ 
tem  with  explicit  self-transitions  among  the  modes  may  allow  a 
self-transition  to  be  taken  even  if  exit  is  another  possibility. 


No. 

Description 

Property 

1 

If  CD  is  tampered  with,  then 
key  1  in  keybank  1  is  zeroized 

@T(mTamper) 

^  cKeyBanklKeyl'  =  0 

2 

When  the  zeroize  switch  is  activated, 
key  1  in  keybank  1  is  zeroized 

@T(mZeroizeS  witch  =  on) 

=>  cKeyBanklKeyl'  =  0 

3 

No  key  can  be  stored  in  location  1 
of  keybank  1  before  an  algorithm 
has  been  loaded  into  the  first  location 
of  algorithm  storage  segment  1 

cKeyBanklKeyl  ^  0 
=>  cAlgStoreSegmentl  4  0 

4 

If  backup  power  has  an  undervoltage 
when  primary  power  is  unavailable, 
the  CD  enters  either  Alarm  mode  or 

Off  mode 

@T(mBackupPower  =  undervoltage) 
WHEN  mPrimaryPower  =  unavailable 
=>  smOperation'  =  sAlarm 

OR  smOperation'  =  sOff 

5 

If  backup  power  is  overvoltage 
then  the  CD  is  in  Initialization, 

Standby,  Alarm,  or  Off  mode 

mBackupPower  =  overvoltage 
=>  smOperation  =  sinitialization 

OR  smOperation  =  sStandby 

OR  smOperation  =  sAlarm 

OR  smOperation  =  sOff 

6 

If  primary  power  has  an  overvoltage 
then  either  the  CD  is  in  Initialization, 
Standby,  Alarm,  or  Off  mode,  or  the  CD 
enters  Initialization  mode 

@T(mPrimaryPower)  =  overvoltage 
=>  smOperation  =  sStandby 

OR  smOperation  =  sAlarm 

OR  smOperation  =  sOff 

OR  smOperation'  =  sinitialization 

7 

If  primary  power  has  an  undervoltage 
then  either  the  CD  is  in  Initialization, 
Standby,  Alarm,  or  Off  mode,  or  the  CD 
enters  Initialization  mode 

@T(mPrimaryPower)  =  undervoltage 
=>  smOperation  =  sStandby 

OR  smOperation  =  sAlarm 

OR  smOperation  =  sOff 

OR  smOperation'  =  sinitialization 

Figure  6.  Security  properties  CD  must  satisfy. 


variables,  three  auxiliary  variables,  and  19  output  vari¬ 
ables).  Eigure  6  lists  the  seven  security  properties  that 
we  verified  with  the  SCR  tools. 

5.2.  Proving  Security  Properties  Using  Invariants 

Our  experience  is  that  state  invariants  automatically 
generated  using  KEEP  and  GROUP  are  often  sufficient 
to  establish  interesting  safety  properties.  These  gener¬ 
ated  invariants  played  an  extremely  useful  role  when 
applied  in  conjunction  with  TAME,  a  user  interface 
to  PVS  that  can  prove  many  invariants  automatically. 
In  the  case  of  CD,  the  automatically  generated  state 
invariants  produced  by  KEEP  and  GROUP  were  suffi¬ 
cient  to  complete  the  proofs  of  all  valid  security  prop¬ 
erties  that  were  investigated. 

TAME  was  able  to  prove  four  of  the  CD  security 
properties  (3,  5,  6,  and  7  in  Eigure  6)  automatically. 
To  prove  the  remaining  three  properties,  TAME  re¬ 
quired  the  user  to  apply  the  five  auxiliary  invariants® 
listed  in  Eigure  7.  The  KEEP  algorithm  generated  the 
unbracketed  parts  of  the  invariants,  with  the  remain¬ 
ing  bracketed  parts  ([  ])  generated  by  GROUP.  KEEP 
generated  the  fifth  invariant  from  the  event  table  for 
cKeyBanklKeyl  with  “cKeyBanklKeyl  =  0”  treated  as 
one  mode  and  “cKeyBanklKeyl  ^  0”  treated  as  a  sec¬ 
ond  mode.  The  KEEP  invariants  are  not  strong  enough 

®The  more  general  form  of  KEEP  generated  additional  in¬ 
variants  not  used  here,  e.g.,  the  mode  invariant  for  sStandBy: 
mBackupPower  ^  {unavailable, undervoltage}  A  (-imTamper  A 
mZeroizeSwitch  7^  on  A  mHealthyFull  V  mPrimaryPower  7^ 
unavailable).  This  invariant,  much  stronger  than  the  invari¬ 
ant  generated  by  Theorem  1,  demonstrates  the  power  of  KEEP. 


Mode 

Invariant  for  mode 

sinitialize 

[  mPrimaryPower  7^  unavailable  ] 

sConf iguration 

mBackupPower  7^  overvoltage 
[  A  mPrimaryPower  7^  unavailable  ] 

sidle 

mBackupPower  7^  overvoltage 
[  A  mPrimaryPower  7^  unavailable  ] 

sTraf f icProcessing 

mBackupPower  7^  overvoltage 
[  A  mPrimaryPower  7^  unavailable  ] 

“cKeyBanklKeyl  7^  0” 

smOperation  7^  sOfF 

Figure  7.  Invariants  generated  for  CD 


to  prove  the  fourth  security  property — the  invariants 
generated  by  GROUP  are  also  required.  All  of  these  re¬ 
sults  were  also  verified  with  the  SCR  property  checker 
Salsa  [6]. 

Our  invariant  generation  tool  implements  part  of  the 
KEEP  algorithm.  For  example,  our  tool  constructed 
the  unbracketed  results  in  the  first  four  lines  of  Fig¬ 
ure  7.  However,  the  fifth  invariant,  which  was  con¬ 
structed  from  an  event  table,  and  the  invariant  men¬ 
tioned  in  footnote  6,  were  generated  by  hand.  The 
GROUP  algorithm  has  not  yet  been  implemented. 

6.  Related  Work 

Our  KEEP  and  GROUP  algorithms  for  generat¬ 
ing  invariants  from  SCR  specifications  extend  work  by 
Atlee  and  Gannon  [3,  4],  who  used  mode  invariants 
to  analyze  SCR  specifications  with  the  MCB  model 
checker.  However,  their  automated  technique  only  ad¬ 
dressed  a  special  case  of  our  KEEP  algorithm  and  did 
not  cover  the  GROUP  technique.  Their  work  provided 
the  inspiration  for  our  research  on  mode  invariant  gen¬ 
eration. 

Mode  invariants  are  similar  to  local  invariants  of 
programs,  where  the  program  location  is  analogous  to 
the  mode.  Bensalem  and  his  colleagues  have  refined 
techniques  for  generating  local  invariants  [5].  However, 
their  generation  process  is  different  from  ours.  For  each 
process  they  determine  “generalized  reaffirmed  invari¬ 
ants  without  (with)  cycles”  which  are  analogous  to  our 
mode  entry  condition  computation  (GROUP  computa¬ 
tion).  The  invariants  from  the  processes  are  combined 
into  overall  system  invariants.  In  contrast,  we  consider 
a  single  process  (a  mode  machine)  with  effects  of  other 
processes  expressed  by  the  constraints  (Gi  and  G2). 

Recently,  researchers  at  SRI  have  developed  a  theo¬ 
retical  framework  for  invariant  generation  based  upon 
under-  and  over-approximation  of  inductive^  invari¬ 
ants  [25].  An  under- approximation  is  a  formula  that 
is  too  strong  to  be  an  invariant,  while  an  over¬ 
approximation  is  a  formula  that  is  an  invariant,  but  is 

formula  is  inductive  if  it  satisfies  (i)  0^  =>  q,  and  (ii) 
qApA  ^  q'  ■ 


weaker  than  the  best  invariant.  In  this  framework,  each 
computation  of  mode  entry  conditions  at  step  1  of  a 
pass  of  the  KEEP  algorithm  is  an  under-approximation 
of  the  mode  invariants.  The  remaining  two  steps  of 
KEEP  provide  an  inductive  over-approximation.  The 
first  step  of  the  GROUP  algorithm  is  also  an  under¬ 
approximation.  The  remaining  steps  of  GROUP  com¬ 
prise  another  inductive  over-approximation,  which  pro¬ 
vides  invariants  that  often  strengthen  the  results  com¬ 
puted  by  KEEP.  We  have  also  shown  (see  [19])  how 
these  approximations  relate  to  abstract  interpretation 
with  widening  and  narrowing  [8]. 

Other  static  techniques  which  analyze  a  state  ma¬ 
chine  specification  include  the  techniques  of  Halb- 
wachs  [9]  and  of  Bjprner  et  al.  [7].  In  Halbwachs’  tech¬ 
nique,  a  system  is  represented  as  a  system  of  linear 
inequalities,  whose  solution  (a  convex,  closed  poly¬ 
hedron)  is  determined  by  successive  approximations. 
While  our  techniques  generate  only  simple  invariants, 
Bjprner  et  al.  have  investigated  the  generation  of  gen¬ 
eral  safety  properties,  using  past  temporal  operators 
over  the  evolution  of  the  system. 

There  are  also  dynamic  techniques  for  obtaining  in¬ 
variants.  Ernst  et  al.  [12]  obtain  “potential  invari¬ 
ants”  for  programs  by  monitoring  likely  expressions 
over  many  executions  (although  these  would  then  have 
to  be  proved  sound). 

7.  Conclusions 

We  have  developed  a  new  algorithm,  GROUP,  which 
improves  upon  invariants  generated  by  a  previous  al¬ 
gorithm,  KEEP.  Because  our  algorithms  produce  in¬ 
tuitive,  readable  invariants  (as  compared  to  the  more 
complete,  detailed  invariants  that  would  be  generated 
by  a  full  reachability  analysis  of  the  mode  machine  E^) , 
our  invariants  can  be  presented  to  system  users  for  val¬ 
idation. 

Our  algorithms  are  designed  for  SCR  systems,  but 
we  have  strived  for  generality  that  should  make  them 
applicable  to  other  ways  of  modeling  systems.  The 
SCR  concepts  of  the  One  Input  Assumption  and 
“strong  causality”  (i.e.,  transitions  “must  occur”  when 
an  appropriate  event  occurs,  as  opposed  to  a  weaker 
concept  of  “may  occur”)  support  systems  with  stronger 
invariants  than  would  occur  without  such  assumptions. 
Nevertheless  both  the  KEEP  and  the  generalized  ver¬ 
sion  of  GROUP  (Theorem  4)  do  not  require  these  as¬ 
sumptions.  Nor  do  they  require  determinism.  In  the 
future  we  will  investigate  the  applicability  of  both  algo¬ 
rithms  to  other  state-based  models  such  as  TLA  (Tem¬ 
poral  Logic  of  Actions)  [21],  Reactive  Modules  [1],  and 
RSML-"  [24]. 
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In  practice,  we  have  found  that  both  the  GROUP 
and  KEEP  algorithms  are  needed  for  generating  aux¬ 
iliary  lemmas  useful  in  proving  major  system  proper¬ 
ties  of  requirements  specifications.  Our  experience  ap¬ 
plying  these  two  methods  to  a  cryptographic  device 
showed  that  these  generated  invariants  were  sufficient 
for  proving  the  desired  security  properties.  Although 
there  is  no  guarantee  that  this  will  always  happen,  our 
experience  suggests  that  applying  invariant  generation 
is  a  useful  first  step  in  verifying  a  set  of  properties, 
particularly  since,  once  both  algorithms  are  completely 
implemented  in  the  SCR  toolset,  invariant  generation 
will  be  fully  automatic. 
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